It is not uncommon today for computing environments to provide for multiple processes operating simultaneously, e.g., multitasking and multiprocessing. For example, many windows environments, such as Microsoft WINDOWS, provide for multitasking through time-sliced execution of multiple processes. Similarly, many layered operating systems, such as HP-UX (available in various forms from manufacturers such as Hewlett Packard Company, Santa Cruz Operation, Inc., and International Business Machines Corporation), provide for multitasking through time-sliced execution of multiple processes and for multiprocessing through dividing processes among multiple processing units.
It is often desirable to provide for exchange of data between the aforementioned multiple processes. For example, multiple processes may be implemented in processing information such that results from one process are aggregated or otherwise complied by another process, thereby requiring information communication between the processes. Similarly, processes may communicate information such as a current operational state, resource utilization information, etcetera among one another in order to facilitate desired computing operation.
Libraries have been developed for use with a particular corresponding operating system to facilitate data communication between multiple processes operable in that operating system environment. However, such development efforts, and the resulting libraries, have not been without difficulty and disadvantages. For example, it has been necessary in the past to develop unique libraries for each operating system due to the unique ways in which each such operating system functions and is configured.
One previous technique for providing data communication between multiple processes in a computing environment has been to implement a pipe, a link between one process' standard output to another process' standard input via the operating system kernel. However, the pipe buffer size is different from operating system to operating system. That is to say, for example, the pipe buffer size may be 32K on WINDOWS NT while the pipe buffer is 8K on HP-UX. Accordingly, if a process were to communicate 32 kilobytes of data in WINDOWS NT, a single pipe call with a single context switch could be executed for the transfer. However, if a similar process were to communicate the same 32 kilobytes of data in HP-UX, a single pipe call with a series of 4 context switches would be implemented.
These differences between the operating systems can require that each corresponding library be uniquely adapted for operation on the appropriate operating system. For example, different messaging protocols may be adopted depending upon the operating system, such as threads in a WINDOWS environment and signal handlers in a HP-UX environment.
Moreover, adaptation to enable a receiving process to identify data received via pipe transfers as part of a same data transmission may be desired in order to provide predictable results. For example, a pipe transmission from a third process may erroneously be interleaved between pipe transmissions of the aforementioned series of 4 context switches used to communicate 32 kilobytes of data.
Such implementation differences among the various operating systems has required the development, maintenance, and support of unique sets of code to implement communication among multiple processes on each operating system. For example, code for providing a process-to-process communication library call in HP-UX includes differences unique to that operating system requiring code for providing a process-to-process communication library call in WINDOWS to be substantially different. Therefore, although providing similar functionality, a duplication of resources is required for developing and maintaining libraries for each different operating system.
Performance using pipes for communicating data is often relatively poor as a process transmitting data via a pipe will be suspended from further processing by the operating system until the receiving process has fully received the pipe data. For example, where processes A and B are operable in a HP-UX environment and it is desired to communicate 32 kilobytes of data from process A to process B, process A may call a pipe to communicate the first 8 kilobytes of data. During the communication of the first 8 kilobytes of data the operating system will preempt process A so that process A has to wait until process B has fully received the first 8 kilobytes of data. The operating system will then release process A and process A can again call a pipe to communicate the second 8 kilobytes of data. During the communication of the second 8 kilobytes of data the operating system will again preempt process A. This continues until process A has “piped” all of the data to process B. Accordingly, it can be very slow and inefficient to implement pipes in providing data communication between such processes.
Further aggravating the above described inefficiencies, pipe transmissions are typically atomic if less than the pipe buffer size, but not if the pipe buffer is exceeded. Accordingly, process B has no way of detecting if the subsequent pipe transmissions are from process A, thereby supplementing the previous data, or from another process (e.g., process C) which fortuitously implements a pipe transmission to process B between the context switches of a pipe transmission from process A. Process B may be unable to determine that the received data is not all related and, therefore, further processing may be flawed or terminated. However, even where the receipt of such interleaved data is detected, process B would be required to establish communication with process A, such as via a pipe transmission, to request retransmission of the data. Such situations can result in unpredictable results and appreciable delays.
It should be appreciated that although particular operating systems such as WINDOWS, may provide a pipe buffer size suitable to accommodate the transmission of desired amounts of data using a single pipe call and/or single context switch, the implementation of such techniques for data transmission between processes is not without disadvantage. For example, as discussed above, process A operating in a WINDOWS environment would be preempted by the operating system during the transmission of the aforementioned 32 kilobytes of data until such time as process B has fully received the piped data. Accordingly, process A is suspended from further processing during the pipe transmission, resulting in relatively poor performance of the system.
A further disadvantage of the aforementioned pipe communications common among the various operating systems upon which the technique may be implemented is the copying of the data twice as it moves from the first process, through the operating system kernel, to the second process. For example, where pipes are used to transmit data from process A to process B, the operating system copies the data from process A to the kernel memory first then the operating system will copy the data from the kernel memory to process B's local memory. Moreover, the transfer of a large amount of data in particular operating systems, such as HP-UX discussed above, may implement the aforementioned series of context switches, further compounding the number of data copies involved.